\documentclass[a4paper,10pt, xcolor=dvipsnames]{beamer}
%\documentclass[a4paper,10pt, xcolor=svgnames]{beamer}
%\documentclass[a4paper,10pt, xcolor=dvipsnames, handout]{beamer}

\input{preambulo.tex}

% ----------------------------------------------------------------------

%\title{On The Criteria To Be Used In Decomposing Systems Into Modules
        %- David Parnas}
\title{Lectura y Presentaci\'on de Papers Fundacionales}
\author{
            %Lectura y Presentaci\'on de Papers Fundacionales
            %\\ \vspace*{0.3cm}
            Nicol\'as Varaschin, Cristian Mart\'inez, 
            Daniel Paz, Nadia Heredia
            \vspace*{-0.5cm}
        }
\date{
        Ingenier\'ia de Software 2 
        \\ \vspace*{0.3cm}
        22 de Noviembre de 2012
      }

% ----------------------------------------------------------------------

\begin{document}

%-- Titlepage --%
\begin{frame}[plain]
\titlepage
\end{frame}

% ----------------------------------------------------------------------

\begin{frame}{Paper elegido}

\textsl
{
    David Parnas. 
    On the Criteria to be Used in Decomposing Systems into Modules. 
    Communications of the ACM. 
    Diciembre de 1972.
}

\begin{wrapfigure}{l}{0.2 \textwidth}
    \includegraphics[width = 0.18 \textwidth]{./img/david_parnas.jpg}
    \caption{David Parnas}
\end{wrapfigure}

\vspace*{0.3cm}

%Biograf\'ia de parnas

Parnas es de Canad\'a, y fue un pionero de la ingenier\'ia de software.
%como todos
Introdujo el concepto del ocultamiento de la informaci\'on, 
que es actualmente un elemento muy importante de la 
programaci\'on orientada a objetos. 

Se recibi\'o como ingeniero el\'ectrico y fue uno de los primeros en
aplicar conceptos tradicionales de ingenier\'ia al diseño de software.

Recibi\'o varios premios, entre ellos el de mejor paper y es doctor
honoris causa en varias universidades.
%pero no es turing award :o

\end{frame}

% ----------------------------------------------------------------------

\begin{frame}{Introducci\'on}

    \begin{itemize}
        \item
                Aunque muchos estén de acuerdo en que la descomposición
                en módulos es recomendable, no queda siempre claro 
                como hacerlo.
        
        \item
                En este paper se presenta un sistema simple y se 
                proponen dos descomposiciones posibles.
    
        \item
                Luego, se analizan respecto a ciertos par\'ametros, 
                mostrando las ventajas de la segunda descomposici\'on.
    
        \item
                En la primera descomposici\'on se usa el flujo de 
                datos, y en la segunda el ocultamiento de la 
                informaci\'on.
    \end{itemize}

\end{frame}

% ----------------------------------------------------------------------

\begin{frame}{Importancia del paper}

    \begin{itemize}
        \item
                Presenta el concepto de information hiding que
                termin\'o siendo muy importante para la
                programaci\'on orientada a objetos.
                
        \item
                Con un ejemplo muestra que el hecho de usar
                information hiding es util y que usar una
                descomposici\'on basada en data-flow no tanto.
                
        %\item
                
    \end{itemize}

\end{frame}

% ----------------------------------------------------------------------

\begin{frame}{Puntos principales}

    La modularización
    \begin{itemize}
        \item
                mejora la flexibilidad.
                Se puede modificar dr\'asticamente un m\'odulo sin que
                el resto se vea afectado.
                
        \item
                mejora la comprensi\'on.
                Deber\'ia ser posible estudiar el sistema de a un
                m\'odulo a la vez.
                % El sistema se puede diseñar mejor porque 
                % se entiende más.
                
        \item
                permite acortar el tiempo del desarrollo.
                Se puede paralelizar el trabajo.
                
        \item
                permite desarrollar un m\'odulo con poco conocimiento
                de los dem\'as.
    \end{itemize}

    \vspace*{0.3cm}
    
    La eficiencia de la modularización depende los criterios utilizados.
    
    %\vspace*{0.1cm}
    
    %Un módulo se entiende como una asignación de responsabilidad 
    %(y no necesariamente un subprograma).
    
    \vspace*{0.3cm}
    
    Par\'ametros de comparaci\'on
    \begin{itemize}
        \item   Modificabilidad.
        \item   Desarrollo Independiente.
        \item   Comprensi\'on.
    \end{itemize}
    
\end{frame}

% ----------------------------------------------------------------------

\begin{frame}{Puntos principales - Par\'ametros de Comparaci\'on}

    \textbf{Modificabilidad}
    \begin{itemize}
        \item                
                ¿Cu\'ales fueron las decisiones de diseño tomadas?
                
        \item 
                ¿Qu\'e pasa si las decisiones cambian?
                ¿Es probable que cambien?                
                
        \item
                ¿Cu\'anto impactan los cambios?
    \end{itemize}
    
    \vspace*{0.3cm}
    
    \textbf{Desarrollo Independiente}
    \begin{itemize}
        \item                
                ¿Cu\'an facil es escribir un m\'odulo de forma
                independiente de los dem\'as?
                
        \item 
                ¿Las interfaces entre los m\'odulos son claras?
    \end{itemize}
    
    \vspace*{0.3cm}
    
    \textbf{Comprensi\'on}
    \begin{itemize}
        \item                
                ¿Cu\'an facil es entender un m\'odulo sin tener
                conocimiento de los dem\'as?
    \end{itemize}

\end{frame}

%Ambas funcionan, la primera descomposición es más convencional, y la
%se usa a veces como proyecto de clases (?).
%Ambas reducen la programación del sistema a la relativamente
%independiente programación de un números de programas chicos y 
%manejables (los módulos).
%
%Las diferencias están en la manera en que se divide el trabajo, y en
%las interfaces entre los módulos.
%
%Los sistemas son sustancialmente diferentes aunque sea idénticos en
%tiempo de ejecución.

% ----------------------------------------------------------------------

\section{Conclusiones}
\begin{frame}{Conclusiones}
    
    Qu\'e aprendimos al leer este paper
    
    \vspace*{0.3cm}  
    
    \begin{itemize}
        \item
                Que no s\'olo es importante dividir en m\'odulo sino
                saber c\'omo hacerlo (qu\'e criterio usar).   
        
        \item
                Que generalmente es incorrecto realizar una
                descomposici\'on bas\'andose en un diagrama de flujo.
                
        \item
                Que una forma m\'as correcta de descomponer es haciendo
                que cada m\'odulo oculte decisiones de diseño 
                importantes o de cosas que probablemente cambien.\\
                (Los m\'odulos no se corresponden con etapas de
                procesamiento).
    \end{itemize}
\end{frame}

% ----------------------------------------------------------------------

\end{document}
